A  Demonstration  of  a 
Computationally  Intensive 
Situation  Awareness  Methodology 

by  Howell  Caton 
and  Frederick  S.  Brundick 


ARL-TR-2025  August  1999 


Approved  for  public  release:  distribution  is  unlimited. 


Dnc  QUALiry  inspected  4 


The  findings  in  this  report  are^not  to  be  consttu  as  an  offidal 
Department  of  the  Army  position  unless  so  desig^i^d  by  other 
authorized  documents. 

Citation  of  manufacturer’s  or  trade  names  does  notcbnsdtute  an 
ofBcial  endorsemeirt  or  approval  of  the  use  thereof.  / 

Destroy  this  report  when  it  is  no  longer  deeded.  Do  not  retunf 
it  to  the  origiiuktor. 


Army  Research  Laboratory 

Aberdeen  Proving  Ground,  MD  21005-5067 

ARL-TR-2025  August  1999 


A  Demonstration  of  a  Computationally 
Intensive  Situation  Awareness 
Methodology 

Howell  Caton  and  Frederick  S.  Brundick 

Information  Science  and  Technology  Directorate,  ARL 


Approved  for  public  release;  distribution  is  imlimited. 


Abstract 


This  report  describes  a  demonstration  of  a  situation  awareness  methodology  that  is  driven  by 
modular  semi-automated  force  (ModSAF),  a  battlefield  simulation  used  throughout  the 
Department  of  Defense  (DOD).  The  methodology  relies  on  information  distribution  technology 
(IDT)  to  minimize  message  traffic  over  bandwidth-restricted  combat  net  radios.  The  use  of 
ModSAF  will  allow  IDT  applications  to  be  a  part  of  other  simulations  and  help  transfer  that 
technology  to  other  systems. 
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Executive  Summary 


This  report  describes  the  Computation  Based  Situation  Awareness  Methodology  Demon¬ 
stration  (CBSAMD).  The  CBSAMD  uses  a  model-based  computationally  intensive  paradigm 
to  implement  situation  awareness,  as  opposed  to  a  more  traditional  message-based  com¬ 
munications  intensive  paradigm.  The  advantage  of  such  a  paradigm  is  to  conserve  radio 
bandwidth,  a  very  scarce  resource  on  the  tactical  battlefield.  Single  Channel  Ground  and 
Airborne  Radio  System  (SINCGARS)  radios,  in  particular,  axe  restricted  in  this  regard).  For 
situation  awareness  (SA)  to  exist  on  the  modern  battlefield,  information  must  be  collected, 
correctly  routed,  and  assimilated.  This  must  occur  automatically  as  to  leave  the  soldier  free 
to  fight  the  battle.  In  current  systems,  the  tendency  is  to  supply  position  awareness  and  not 
situation  awareness.  Joint  Surveillance  Taxget  Attack  Radar  System  (JSTARS)  images,  as 
seen  in  Desert  Storm  press  releases,  show  where  vehicles  are  but  do  not  indicate  how  well 
the  mission  is  progressing.  Only  when  the  analyst  combines  current  positional  data  for  both 
friendly  and  enemy  forces  with  the  maneuver  plan,  associates  units  with  the  vehicles,  and 
compares  their  locations  to  where  they  are  expected  to  be  is  true  SA  obtained. 

The  CBSAMD  was  constructed  from  the  modules  described  next.  Each  module  is  a 
separate  application  and  has  one  or  two  primary  functions. 

•  Modular  Semi- Automated  Forces  (ModSAF)  is  a  battlefield  simulation  that  drives  the 
demonstration.  It  generates  position  and  functionality  data  for  every  fighting  entity 
on  the  battlefield. 

•  Distributed  Interactive  Simulation  (DIS)  Manager  is  an  application  program  suite  that 
formats  data  generated  by  ModSAF  so  that  it  can  be  easily  understood  by  humans. 

•  Protocol  Data  Unit  (PDU)  Filter  filters  information  out  of  DIS  Manager's  output  that 
is  relevant  to  the  demonstration.  It  is  written  in  Perl  a  general-purpose  interpreted 
language.  Perl  is  a  language  for  easily  manipulating  text,  files,  and  processes.  It  does 
many  jobs  that  were  formerly  done  by  C  programs,  shell  programs,  and  text  editors 
such  as  Stream  Editor  (SED). 

•  Berkeley  Socket  Client  Application  (BSCA)  opens  a  socket  on  a  server  application 
running  on  a  demonstration  node  and  writes  data  to  it. 

•  Berkeley  Socket  Server  Application  (BSSA)  receives  data  and  writes  it  to  the  Posi¬ 
tion/Sensing/Ammunition  (P/S/A)  Tee. 

•  P/S/ A  Tee  is  a  Perl  program  that  splits  the  data  into  two  streams  and  pipes  one  to 
Route  Check  and  the  other  to  the  “Factbase”  Input  Utility  (FIU). 

•  Route  Check  accepts  the  actual  position  of  a  unit  as  input  and  compares  the  actual 
position  with  its  planned  location. 

•  Shape  of  Certainty  (SOC)  Monitor  is  notified  by  the  Distributed  “Factbase”  (DFB) 
when  the  current  unit  is  not  where  it  is  expected  to  be,  as  defined  by  its  sequential 
objectives  and  tolerance. 
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•  FIU  enters  enemy  deployment  and  ammunition  usage  information  into  the  DFB. 

•  DFB  contains  a  database  describing  the  current  situation,  plans,  and  reference  data: 
provides  interprocess  communication  between  the  modules;  and  sends  and  receives  data 
to/from  other  DFBs  over  combat  net  radios. 

•  Display  Manager  graphically  shows  sequences  and  planned  locations  of  all  units  and 
actual  position  of  current  unit. 

The  interaction  of  the  various  modules  is  depicted  in  Figure  ES-1,  shown  on  the  next  page. 
Distribution  of  the  data  is  controlled  by  the  DFB.  It  contains  a  set  of  rules  that  tells  it  when 
to  communicate  with  other  units  (actually  their  DFBs)  and  what  data  to  send.  Other  rules 
notify  applications  when  certain  actions  occur  (e.g..  a  unit's  planned  movements).  By  having 
all  the  applications  store  data  in  the  DFB,  it  is  much  easier  to  replace  one  application  with 
another.  The  programs  need  to  know  how  to  interface  with  the  DFB,  not  with  each  other. 
A  unit  will  be  running  several  applications  connected  to  its  DFB,  not  just  the  ones  described 
previously  for  SA.  The  SA  programs  plug  into  the  existing  DFB  and  communication  systems. 


Figure  ES-1.  Block  Diagram  of  SA  Demonstration. 
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1.  Introduction 


Information  distribution  technology  (IDT)  was  a  long-term  research  project  of  the  Com¬ 
munications  and  Network  Division  of  the  Information  Science  and  Technology  Directorate 
(IS&TD)  of  the  U.S.  Army  Research  Laboratory  ( ARL).  IDT  combined  the  power  of  the  mod¬ 
ern  digital  computer  with  the  tenets  of  model-based  battle  command  (Chamberlain  1990). 
By  devising  a  way  of  exchanging  tactical  information  over  low-bandwidth  channels  (i.e., 
combat  net  radios),  sophisticated  command  and  control  tools  could  be  deployed  to  lower 
echelons  than  previously  possible.  The  Computation  Based  Situation  Awareness  Methodl- 
ogy  Demonstration  (CBS AMD)  described  in  this  report  was  built  by  members  of  the  IDT 
team.  It  extends  the  IDT  methodology  to  perform  situation  awareness  by  including  the 
deployment  of  enemy  units.  Observations  of  enemy  units  are  entered  into  the  Distributed 
“Factbase”  (DFB)  as  sensing  facts.  Another  innovative  aspect  of  the  CBSAMD  is  the  use 
of  the  Modular  Semi- Automated  Forces  (ModS.AF)  software,  a  widely  used  battlefield  sim¬ 
ulation,  as  the  driver. 

The  scenario  for  the  CBSAMD  is  a  chance  encounter  between  a  single  MlAl  tank  platoon 
and  two  T80  platoons.  The  MlAl  platoon  is  accompanied  by  a  single  AH-64D  (Apache) 
helicopter,  and  the  T80  platoons  are  accompanied  by  a  single  Mi24  helicopter.  The  five 
nodes  of  the  demonstration  represent  the  computer  and  communication  resources  of  the 
four  MlAl  tanks  and  the  Apache  helicopter.  At  the  beginning  of  the  CBS.4MD,  every 
node  starts  its  own  DFB  and  other  applications.  The  applications  connect  to  the  DFB 
and  extract  whatever  initial  data  they  need;  for  example.  Route  Check  gets  all  sequential 
objectives.  ModSAF  is  started  and  the  scenario  is  loaded.  The  Distributed  Interactive 
Simulation  (DIS)  Manager  server  program  is  started.  The  ModSAF  exercise  is  started.  The 
DIS  Manager  client  program  is  started,  and  the  Berkeley  Socket  Client  Application  (BSCA) 
program  connects  to  the  Berkeley  Socket  Server  .Application  (BSSA).  Then,  at  fi.xed  time 
intervals,  the  following  steps  occur. 

(1)  The  Protocol  Data  Unit  (PDU)  Filter  filters  out  position  data,  ammunition  usage, 
and  observations  of  enemy  units. 

(2)  The  BSC.A  pipes  the  data  to  the  BSSA. 

(.3)  The  Position/Sensing/ Ammunition  (P/S/.A)  Tee  splits  the  data  into  two  streams.  One 
stream  feeds  ammunition  usage  and  observations  of  enemy  units  into  the  "Factbase' 
Input  Utility  (FIU)  and  the  other  feeds  position  data  into  Route  Check. 

(4)  The  FIU  stores  ammunition  usage  and  enemy  deployment  in  the  DFB. 

(5)  Route  Check  computes  the  planned  location  of  every  desired  unit  and  stores  the  results 
in  the  DFB. 

(6)  Route  Check  determines  if  the  current  position  is  within  the  allowable  area  of  the  unit’s 
planned  location. 

(7)  Route  Check  stores  the  actual  position  and  the  result  of  step  (6)  in  the  DFB. 
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(8)  The  DFB  notifies  the  Display  Manager  that  certain  units  have  moved  so  it  may  update 
its  map. 

(9)  If  the  unit  is  not  where  it  is  expected  to  be,  the  DFB  alerts  the  Shape  of  Certainty 
(SOC)  Monitor  application.  Other  DFBs  may  be  notified  by  radio. 

(10)  The  process  repeats. 

The  modules  and  steps  described  previously  were  designed  to  provide  SA  with  minimal 
radio  traffic  by  using  preplanned  sequential  objectives  and  model-based  battle  command. 


2.  Components  of  the  CBSAMD 
2.1  ModSAF 

ModSAF  is  a  powerful  battlefield  simulation  that  has  much  of  the  military  science  built 
in  (i.e.,  the  operator  does  not  have  to  control  the  reaction  of  units  to  obstacles  presented 
by  terrain  or  enemy  units).  Furthermore,  ModSAF  will  react  to  a  specific  situation  in 
different  ways  at  different  times,  as  might  different  (or  even  the  same)  military  commanders. 
This  feature  helps  to  ensure  the  realism  of  enemy  engagements.  This  feature  also  adds  the 
challenge  of  forcing  the  IDT  software  to  adapt  to  unforeseen  situations.  ModSAF  creates  and 
controls  entities  within  a  simulated  battlefield.  Its  goal  is  to  replicate  the  outward  behavior 
of  units  and  their  component  vehicles  and  weapons  system. 

A  ModSAF  exercise  can  be  conducted  by  multiple  parties  at  widely  separated  locations. 
ModSAF  distributes  information  covering  every  aspect  of  a  battle  over  local-area  networks 
(LANs)  or  the  Internet  though  a  comprehensive  set  of  PDUs.  PDUs  make  up  a  comprehen¬ 
sive  set  of  data  structures  for  organizing  and  distributing  battlefield  information.  There  are 
27  different  PDUs.  The  PDUs  that  contain  data  relevant  to  this  demonstration  are  the  En¬ 
tity  State,  Fire,  and  Signal  PDUs.  The  Entity  State  PDUs  contain  unit  location  and  status 
data.  Fire  PDUs  contain  information  concerning  the  firing  of  weapons.  They  are  used  by 
the  demonstration  to  track  ammunition  usage.  Signal  PDUs  carry  information  concerning 
sightings  of  enemy  vehicles  (Distributed  Interactive  Simulation  1998). 

ModSAF  was  developed  by  Lockheed  Martin  Federal  Systems  Inc.,  .Advanced  Distributed 
Simulation,  for  the  U.S.  Army  Program  Manager  Distributed  Interactive  Simulation  (PM- 
DIS).  It  is  distributed  by  the  Defense  Modeling,  Simulation,  and  Tactical  Technology  In¬ 
formation  .4nalysis  Center  (DMSTTIAC)  Service  Center,  Orlando,  FL.  (Defense  Modeling. 
Simulation,  and  Tactical  Technology  Information  Analysis  Center  1996). 

ModSAF  drives  the  CBSAMD  by  providing  the  time  and  the  unit’s  location  at  fixed  time 
intervals.  It  also  supplies  information  regarding  sightings  of  enemy  vehicles  and  ammunition 
usage.  With  minimal  effort,  the  CBSAMD  could  be  driven  by  input  from  actual  combat 
exercises  or  by  other  simulators. 
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2.2  Distributed  Interactive  Simulation  (DIS)  Manager 

The  DIS  Manager  application  suite  was  written  at  the  U.S.  Army  Research  Laborator} 
(Smith  1994).  It  captures  the  PDUs  transmitted  over  the  network  by  ModSAF.  It  can  output 
the  PDUs  in  binary  or  ASCII  format.  ASCII  format  was  used  in  the  CBSAMD  because  it  was 
easier  to  write  a  program  to  filter  out  the  data  relevant  to  the  demonstration  (PDU  Filter). 
Two  components  of  the  suite  are  used  by  the  CBSAMD.  A  server  component  intercepts  the 
PDUs,  and  a  client  component  formats  the  PDUs  and  prints  them. 


2.3  PDU  Filter 

PDU  Filter  is  a  program  written  in  the  Perl  language.  Perl  is  a  language  for  easil} 
manipulating  text,  files,  and  processes.  It  does  many  jobs  that  were  formerly  done  by  C 
programs,  shell  programs,  and  Stream  Editor  (SED)  (Wall  and  Swartz  1990).  PDU  Filter  is 
used  to  to  filter  position,  ammunition  usage,  and  enemy  sighting  data  from  the  PDU  data 
stream.  It  then  reformats  the  data  into  the  syntaces  understood  by  the  FIU  and  Route 
Check.  The  output  feeds  as  a  single  stream  into  the  BSCA.  The  two  types  of  data  are 
separated  at  the  other  end  of  the  Berkeley  Socket. 

2.4  The  BSCA  and  the  BSSA 

The  data  are  transmitted  from  the  workstation  running  ModS.AF  to  the  nodes  by  way  of 
the  BSCA  and  the  BSSA.  The  BSCA  runs  on  the  ModSAF  workstation  and  connects  to  the 
BSSA,  running  on  the  nodes,  over  the  network  and  pipes  the  data  stream  to  the  BSSA.  The 
BSSA  writes  the  data  to  standard  output  and  echoes  them  back  to  the  BSCA.  The  BSCA 
then  writes  the  data  to  standard  output.  The  writing  of  the  data  to  standard  out  at  the 
client  end  verifies  that  the  data  have  been  successfully  transmitted.  If  the  data  had  somehow 
been  corrupted,  that  fact  could  be  observed  at  this  time.  The  BSC.A  and  the  BSSA  were 
adapted  from  examples  in  Unix  Network  Programming  (Stevens  1998). 


2.5  P/S/ A  Tee 

P /S /A  Tee  is  a  Perl  program  that  separates  position  data  from  ammunition  usage  and 
enemy-sensing  data  by  testing  for  particular  keywords.  It  then  pipes  them  to  different 
applications.  Position  data  are  handled  by  Route  Check;  ammunition  usage  and  enemy 
sensing  data  are  handled  by  the  FIU. 


2.6  Route  Check 

The  Route  Check  application  is  the  component  that  deals  with  the  sequential  objectives. 
It  extracts  all  primary  and  alternate  sequential  objectives  from  the  DFB  for  the  friendly 
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units  that  the  user  wants  to  track.  When  it  gets  the  time  from  P/S/A  Tee,  it  computes 
the  planned  location  of  each  unit  and  stores  the  information  in  the  DFB.  It  then  compares 
the  known  position  of  the  current  unit  (also  obtained  from  P/S/A  Tee)  with  its  planned 
location,  subject  to  the  allowable  error  tolerance,  called  the  SOC.  The  model  presented  here 
uses  SOCs  that  are  circular.”  Information  on  whether  or  not  the  unit  is  within  its  expected 
area  is  also  stored  in  the  DFB. 


2.7  The  FIU 

The  FIU  is  an  application  written  by  George  Hartwig  of  IS&TD  for  creating  and  updating 
facts  in  the  DFB.  It  was  originally  known  as  Fact  Exchange  Protocol  (FEP)  Driver.  In  its 
native  form,  it  uses  batch  files  as  input.  It  was  modified  to  accept  input  interactively  for  the 
CBS  AMD. 

2.8  DFB 

The  DFB  is  the  hub  about  which  all  data  move  (except  for  the  P/S/A  Tee  Route 
Check  interface).  It  is  an  active  database  that  provides  both  interprocess  communications 
and  connectivity  to  other  DFBs  (Hartwig  1991).  Applications  running  on  a  node  connect 
to  the  DFB  on  that  node.  The  applications  can  register  triggers  (Cohen  1989),  or  active 
queries,  to  monitor  updates  made  to  the  DFB.  When  data  meeting  the  requirements  of  the 
active  queries  are  entered  into  the  database,  the  application  is  notified  by  the  DFB.  These 
data  may  originate  from  another  application  or  from  the  DFB  of  another  node,  through  the 
use  of  data  distribution  rules.  Data  distribution  rules  are  active  queries  that  tell  a  DFB  to 
send  information  to  another  node  when  certain  conditions  are  met.  They  are  part  of  the 
unit's  standing  operating  procedures  (SOPs). 

The  DFB  trigger  mechanism  allows  the  various  applications  to  be  written  with  a  common 
data  interface  instead  of  requiring  them  to  know  how  to  directly  exchange  data  with  each 
other.  This  loose  coupling  permits  different  applications  to  be  used.  Once  the  IDT  applica¬ 
tion  programming  interface  (API)  has  been  incorporated  into  a  program,  it  may  connect  to 
a  DFB,  perform  updates  and  queries,  register  and  process  triggers,  etc.  If  the  programs  ex¬ 
changed  data  directly,  new  interfaces  would  need  to  be  written  every  time  one  of  the  modules 
was  replaced  with  a  different  program. 

The  DFB  gets  the  sequential  objectives  as  part  of  the  operational  orders  (OPORDs). 
Each  friendly  unit  has  a  primary  sequence,  while  alternate  sequences  provide  for  contingen¬ 
cies  like  a  bridge  being  out. 

“For  details  on  the  construction  and  inaplementation  of  SOCs  and  sequential  objectives,  see  Hartwig, 
Brundick.  and  Kothenbeutel  (1996). 
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2.9  Display  Manager 


The  Display  Manager  is  a  graphical  user  interface.  It  retrieves  the  expected  and  last 
known  locations  of  all  units  from  the  DFB  and  plots  them  on  a  map.  It  also  draws  a 
tolerance  area  around  the  expected  locations.  If  a  unit  strays  outside  its  tolerance  area,  a 
data  distribution  rule  instructs  the  DFB  to  notify  the  other  nodes  of  its  actual  location. 
The  Display  Manager  can  display  other  information,  such  as  the  northing  and  easting  of  any 
selected  point  on  the  map.  It  can  also  into  an  identification  mode.  Then  the  user  “clicks” 
on  any  object  on  the  screen  to  get  a  summary  of  information  from  the  DFB.  Another  mode 
demonstrates  how  sequential  objectives  and  SOCs  may  provide  combat  ID.  The  user  clicks 
on  the  map  to  place  his/her  location  and  then  clicks  a  second  time  to  show  his/her  line  of 
sight.  The  program  determines  if  the  line  intersects  any  SOCs,  indicating  that  the  user  is 
seeing  a  friendly  unit. 


2.10  SOC  Monitor 

The  SOC  Monitor  is  an  application  program  that  monitors  the  current  unit’s  location 
and  indicates  when  the  unit  is  out  of  its  tolerance  area.  It  does  so  by  writing  a  message  to 
the  standard  output. 


2.11  Other  Nodes 

The  CBSAMD  includes  five  nodes,  representing  each  of  the  five  friendly  vehicles  in  the 
demonstration:  four  MlAl  tanks  and  an  Apache  helicopter  (AH-64D).  ModSAF  feeds  data 
into  five  copies  of  PDU  Filter,  one  for  each  node.  Each  PDU  Filter  feeds  into  a  separate 
execution  of  BSCA.  Subsequent  to  BSCA,  each  component  of  the  diagram  in  the  Executive 
Summary  is  duplicated  at  each  node.  Only  the  information  pertaining  to  a  particular  node 
is  sent  to  it  over  the  Internet. 


2.12  Radio 

In  accordance  with  the  IDT  model,  information  is  transmitted  between  nodes  only  when 
necessary.  Necessary  information  such  as  contact  with  hostile  forces  is  transmitted  via  Single 
Channel  Ground  and  Airborne  Radio  System  (SINCG.ARS)  radio. 
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3.  Operation  of  the  SA  Demonstration 

3.1  Overview 

The  operation  of  the  model  is  divided  into  three  phases;  initialization  of  the  nodes, 
initialization  of  the  driver,  and  the  execution  phase.  These  phases  are  depicted  in  Figure  1. 


Figure  1.  Operation  of  the  Model. 


Initialization  of  the  nodes  consists  of  independent  actions  that  are  necessary  to  set  up  the 
demonstration.  Several  application  programs  are  started  together.  They  are  Route  Check. 
Display  Manager,  the  FIU.  the  BSSA,  and  P/S/A  Tee.  The  BSSA  must  be  started  before 
the  BSC  A,  or  the  BSC  A  will  fail.  Therefore,  the  nodes  must  be  initialized  before  the  driver 
can  be  initialized.  Initialization  of  the  driver  steps  are  performed  at  the  beginning  of  the 
exercise.  ModSAF  and  the  DIS  Manager  server  program  are  started,  and  the  scenario  is 
loaded  into  ModSAF.  The  DIS  Client  Pipe  shell  script  that  runs  the  DIS  Manager  client 
program,  the  PDU  Filter,  and  the  BSCA  is  poised  to  start.  The  script  pipes  output  from 
the  DIS  Manager  client  program  into  the  PDU  filter  and  pipes  output  from  that  into  the 
BSCA.  This  script  cannot  be  started  until  the  ModSAF  exercise  has  begun. 


3.2  Execution  Phase 

In  the  Execution  Phase,  the  ModSAF  exercise  is  started.  Then  the  DIS  Client  Pipe  shell 
script  is  started.  The  BSCA  connects  to  the  BSSA,  which  was  started  during  the  nodes’ 
initializations.  The  CBSAMD  can  then  proceed  without  human  intervention.  The  reactions 
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of  the  various  units  to  hostile  encounters  is  not  predetermined  and  will  vary  during  separate 
runs  of  the  CBS  AMD.  Optionally,  the  operator  can  intervene  interactively  and  command  a 
particular  unit  to  withdraw  or  advance  to  a  particular  location. 

The  ModSAF  screen  at  the  beginning  of  the  exercise  is  shown  in  Figure  2. 


Figure  2.  Sample  ModSAF  Screen. 


3.2.1  Discussion 

The  flexible  reactions  of  the  fighting  units  and  the  ability  to  command  the  units  subject 
the  the  CBSAMD  software  to  many  of  the  situations  to  which  it  may  be  required  to  respond 
in  actual  combat.  The  military  science  built  into  ModSAF  ensures  the  realism  of  these  sit¬ 
uations.  Any  inappropriate  handling  of  situations  can  be  used  for  debugging  and  improving 
IDT  software.  The  Route  Check  program  receives  the  time  and  computes  where  each  unit  is 
expected  to  be.  Route  Check  stores  the  computed  SOCs  in  the  DFB  so  that  other  modules 
may  retrieve  the  values.  It  also  stores  the  actual  location  as  provided  by  P/S/A  Tee.  along 
with  a  flag  indicating  whether  or  not  the  unit  is  within  its  SOC.  Each  time  P/S/ A  Tee  sends 
location  data  to  Route  Check,  the  SOCs  are  computed  and  everything  is  updated  in  the 
DFB.  Notice  that  no  human  intervention  is  required.  Location  data  are  piped  directly  to 
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Route  Check,  which  does  all  the  analysis  and  stores  the  results  in  the  DFB.  Figure  3  shows 
Display  Manager  several  minutes  after  the  demonstration  was  started.  The  circles  are  the 
SOCs  denoting  each  unit’s  expected  position. 


Figure  3.  Sample  Display  Manager  Screen. 


3.2.2  Course  Deviations 

Other  applications  may  be  notified  when  the  unit  is  outside  of  its  SOC.  The  SOC  Monitor 
program  registers  a  trigger  for  this  purpose.  When  Route  Check  stores  a  location  with  the 
“out  of  SOC”  flag  set,  the  trigger  “fires.”  The  SOC  Monitor  retrieves  the  details  from  the 
DFB  and  prints  them.  A  distribution  rule  causes  the  unit’s  actual  location  to  be  broadcast  at 
the  same  time.  The  small  cross  below  the  SOCs  in  Figure  3  is  the  home  unit’s  real  position. 
It  has  left  its  SOC  because  of  its  reaction  to  the  enemy  units. 
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3.2.3  Display  Manager 

On  startup,  the  Display  Manager  connects  to  the  DFB  and  extracts  all  the  sequential 
objectives.  Each  active  sequence  is  drawn,  using  one  color  for  the  current  unit  and  another 
color  for  all  other  units.  Triggers  are  registered  to  notify  the  Display  Manager  when  the 
following  events  occur: 

•  an  actual  unit  location  is  stored  or  updated  in  the  DFB, 

•  a  SOC  is  stored  or  updated  in  the  DFB,  or 

•  a  unit  switches  to  an  alternate  sequence. 


4.  Useful  Enhancements 

The  CBSAMD  can  be  improved  by  adding  another  ModSAF  driver  to  control  the  enemy 
units.  Two  workstations  would  be  running  the  same  exercise,  each  controlling  opposite  sides 
of  the  battle.  This  step  would  add  realism  in  that  neither  side  could  predict  the  other’s 
movements. 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  promulgates  modeling  and  simu¬ 
lation  policy  among  Department  of  Defense  (DOD)  components.  They  recently  established 
a  common  High-level  Simulation  Architecture  (HLA)  to  which  models  and  simulations  must 
conform.  It  is  recommended  that  the  CBSAMD  be  made  HLA  compliant  in  the  near  future 
(Defense  Modeling  and  Simulation  Office  1998). 

Another  useful  enhancement  would  be  to  distribute  estimates  of  enemy  degraded  perfor¬ 
mance.  On  the  battlefield,  a  human  observer  could  observe,  for  example,  that  the  engine  of 
an  enemy  tank  was  smoking  and  deduce  a  mobility  kill  from  that.  ModSAF  reports  such 
information  through  PDUs. 


5.  Conclusions 

The  structure  and  operation  of  the  CBSAMD,  a  situation  awareness  demonstration  that 
is  driven  by  a  state-of-the-art  battlefield  simulation,  ModSAF,  has  been  described.  Offering 
virtually  “hands-off”  operation,  the  CBSAMD  shows  how  a  major  improvement  in  supplying 
vital  information  to  the  commander  is  possible  without  a  major  increase  in  human  effort. 
Further,  the  CBSAMD  demonstrates  significant  improvements  in  keeping  this  awareness 
current  with  a  minimum  use  of  precious  bandwidth. 

Finally,  a  number  of  enhancements  to  the  CBSAMD  have  been  offered,  which  will  signif¬ 
icantly  improve  its  realism  and  usefulness. 
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List  of  Abbreviations 


API 

Application  Programming  Interface 

ARL 

Army  Research  Laboratory 

BSCA 

Berkeley  Socket  Client  Application 

BSSA 

Berkeley  Socket  Server  Application 

CBSAMD 

Computation  Based  Situation  Awareness 

Methodlogy  Demonstration 

DIS 

Distributed  Interactive  Simulation 

DFB 

Distributed  Factbase 

DMSO 

Defense  Modeling  and  Simulation  Office 

DMSTTIAC 

Defense  Modeling,  Simulation,  and  Tactical 

Technology  Information  Analysis  Center 

DOD 

Department  of  Defense 

FEP 

Fact  Exchange  Protocol 

FIU 

Factbase  Input  Utility 

HLA 

High-level  Simulation  Architecture 

ID 

Identification 

IDT 

Information  Distribution  Technology 

IS&TD 

Information  Science  and  Technology  Directorate 

JSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

LAN 

Local-area  Network 

ModSAF 

Modular  Semi-automated  Forces 

OPORD 

Operational  Orders 

PDU 

Protocol  Data  Unit 

PM-DIS 

Program  Manager  -  Distributed  Interactive  Simulation 

P/S/A 

Position/Sensing/  Ammunition 

SA 

Situation  Awareness 

SINCGARS 

Single  Channel  Ground  and  Airborne  Radio  System 

SOC 

Shape  of  Certainty 

SOP 

Standing  Operating  Procedure 
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